The reverse-iteration idiom `for (size_t idx = n; idx-- > 0;)` decrements
on the final check too, so idx wraps to SIZE_MAX every time the loop ends,
not just when prev_cycles is empty. -fsanitize=integer reports it on each
exit:

  llmq/utils.cpp:519:54: runtime error: unsigned integer overflow:
  0 - 1 cannot be represented in type 'size_t'
  index/addressindex.cpp:309  undoing a block's transactions in reverse
  llmq/snapshot.cpp:194       building the mnlistdiff chain in reverse

src/qt/proposalmodel.cpp:408 uses the same shape but counts with int,
where 0 - 1 is representable, so it is left alone.

CQuorumBlockProcessor stored `Chainstate& m_chainstate`, bound once when
LLMQContext is built in node::DashChainstateSetup(). A reference cannot be
rebound, but the object it names does not live as long as LLMQContext:
ChainstateManager::ResetChainstates() destroys the chainstate and
InitializeChainstate() allocates a new one. Everything the block processor
does afterwards reads freed memory.

AddressSanitizer catches it in validation_chainstate_tests/chainstate_update_tip:

  ERROR: AddressSanitizer: heap-use-after-free
  READ of size 8 at offset 136 inside a 288-byte region
    llmq::CQuorumBlockProcessor::ProcessBlock  llmq/blockprocessor.cpp:171
    CSpecialTxProcessor::ProcessSpecialTxsInBlock  evo/specialtxman.cpp:707
    Chainstate::ConnectBlock  validation.cpp:2320
  freed by
    ChainstateManager::ResetChainstates  validation.cpp:5807

Offset 136 is Chainstate::m_chainman, which is what line 171 dereferences.

Not reachable on a running node today: ResetChainstates() and
ActivateSnapshot() have no callers outside tests, and Dash has no
loadtxoutset RPC, so no snapshot is ever activated. The reference is still
wrong on its own terms though, because ActivateSnapshot() repoints
m_active_chainstate without freeing the old chainstate, which would leave
the block processor validating commitments against the background chain.
Better to fix it now than to wait for assumeutxo to be wired up.

Holding the manager and asking for the active chainstate per call removes
the lifetime question entirely: ChainstateManager is owned by NodeContext
and outlives LLMQContext. It also matches the immediate caller,
CSpecialTxProcessor, which already keeps `const ChainstateManager&`, and
shortens the nine sites that spelled out m_chainstate.m_chainman.

…te reference

Same defect as CQuorumBlockProcessor, in the three remaining long-lived
objects that captured a Chainstate reference at construction:

  chainlock::ChainLockSigner        active/context.cpp:45
  instantsend::InstantSendSigner    active/context.cpp:47
  NetInstantSend                    init.cpp:2179

All three were handed chainman.ActiveChainstate() once and stored the
result as a reference. ChainstateManager::ResetChainstates() destroys that
object, so any use afterwards touches freed memory, and ActivateSnapshot()
repoints the active chainstate without freeing the old one, which would
leave these three working against the background chain.

None is reachable from a test that resets chainstates, so unlike
CQuorumBlockProcessor there is no sanitizer failure to point at. They are
the same bug regardless, and leaving three of four instances in place
would just invite the next one.

NetInstantSend needs a mutable chainstate for InvalidateBlock,
ResetBlockFailureFlags and ActivateBestChain. That still works through a
const manager, because ChainstateManager::ActiveChainstate() is a const
method returning a non-const reference. The LookupBlockIndex at
net_instantsend.cpp:604 goes through ActiveChainstate().m_blockman rather
than the manager's own m_blockman, because the const manager would select
the const overload and the result has to stay writable, as the comment
above it already noted.

SelectQuorumForSigning keeps using ActiveChainstate().m_chain instead of
ActiveChain(); the latter is annotated EXCLUSIVE_LOCKS_REQUIRED(cs_main)
and that call site does not hold it, so the direct member access preserves
the existing locking exactly.

Four RPC handlers were built by a helper that takes a bool, and captured
that bool with [&]. The lambda is stored in the returned RPCHelpMan and
outlives the helper, so by the time a request arrives the parameter's
stack slot is long gone:

  ERROR: AddressSanitizer: stack-use-after-return
  READ of size 1 ... thread T20 (d-httpworker.2)
    protx_register_fund_wrapper(bool)::$_0::operator()  rpc/evo.cpp:528
    RPCHelpMan::HandleRequest  rpc/util.cpp:530
    CRPCTable::execute  rpc/server.cpp:516
    HTTPReq_JSONRPC  httprpc.cpp:242

Affected:

  rpc/evo.cpp:526         protx register_fund / register_fund_legacy
  rpc/evo.cpp:577         protx register / register_legacy
  rpc/evo.cpp:629         protx register_prepare / register_prepare_legacy
  rpc/governance.cpp:689  gobject list / gobject diff

The read decides whether the deprecated legacy BLS scheme is being
requested, and in gobject's case whether to return a diff, so a stale
value silently picks the wrong behaviour rather than failing loudly.

Capturing by value is enough; none of the four bodies uses anything else
from the enclosing scope.

protx_update_registrar_wrapper takes the same kind of parameter but
derives the flag from self.m_name inside the lambda, so it was never
affected. masternodelist_helper and rpc/node.cpp's echo() use their
parameter only while building the RPCHelpMan, before the lambda exists.

This is what made 33 functional tests fail under ASan: every masternode,
LLMQ and governance test registers a masternode, so all of them hit
protx register_fund and died in the same place.

Holding ChainstateManager rather than a Chainstate reference meant reaching
the chain through ChainstateManager::ActiveChain(), which is annotated
EXCLUSIVE_LOCKS_REQUIRED(GetMutex()) with GetMutex() returning ::cs_main.
Neither call site holds it, and the fuzz job builds with -Wthread-safety
-Werror, so this is a hard error there:

    instantsend/signing.cpp:393:90: error: calling function 'ActiveChain'
    requires holding mutex 'cs_main' exclusively
    [-Werror,-Wthread-safety-analysis]

Use the idiom the other two SelectQuorumForSigning callers already use, in
llmq/ehf_signals.cpp and llmq/signing_shares.cpp: take cs_main just long
enough to obtain the reference, then call with it held no longer. In
BuildVerificationBatch the reference is hoisted out of the loop over pending
locks so the lock is taken once rather than per entry.

net_instantsend.cpp reached the chain as ActiveChainstate().m_chain, which
compiles because the member carries no annotation. That is the same
unlocked access, only hidden from the analyser, so it is converted too.

This deliberately does not change what is serialised. The traversal inside
SelectQuorumForSigning still runs without cs_main, exactly as it did before
the refactor, when both sites read m_chainstate.m_chain directly. Holding
cs_main across the whole call would be a real behaviour change: it takes
cs_main on the InstantSend signing path, which is where lock order
inversions live, and belongs in its own change with a tsan run behind it
rather than in a refactor.